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NeXus is an international standard data format intended to reduce the need for redundant software 
development efforts in the neutron and x-ray scattering communities. As the NeXus standard 
matures it is starting to be used at laboratories for storing raw data. The Manuel Lujan Jr. 
Neutron Scattering Center (MLNSC) at Los Alamos National Laboratory and the Intense Pulsed 
Neutron Source (IPNS) at Argonne National Laboratory have been working with NeXus in an effort 
to share data and software. MLNSC is now writing files compliant with NeXus and the Integrated 
Spectral Analysis Workbench (ISAW) software from IPNS is being used with this data. Problems 
can arise if the standard is interpreted in different ways and information that belongs in the file 
is not accounted for in the standard. This paper will discuss an inter-laboratory collaboration in 
relation to a maturing data standard. 



I. INTRODUCTION 

Using an international standard file format for data 
storage is very appealing. Rather than having to write, 
or track down, a conversion utility one can directly use a 
variety of software packages. For scattering data the clear 
choice is to use NeXus. 1 NeXus is a binary file format 
built on top of the Hierarchical Data Format (HDF) 2 
library. The binary format allows for more efficient data 
storage while the hierarchical nature of HDF allows for 
intelligent grouping of information to describe what is in 
the file. 

The early development of NeXus concentrated on pro- 
viding a powerful application program interface (APf) 
implemented in C with wrappers for FORTRAN 77/90, 
IDL, and Java. The variety of supported languages sim- 
plifies the work for those who do want to read or write 
NeXus files directly. More recently the focus turned to 
standardizing the organization of the data and associated 
information. Originally, the NeXus standard provided a 
mechanism for storing information in the file, but did not 
spell out a detailed policy for using that mechanism. In- 
strument definitions were incomplete and did not provide 
enough information to generate truly portable data files. 
This was the main problem when the authors began to 
collaborate. 

NeXus was starting to define what constituted a 
generic compliant file. Each file contains multiple NX- 
entries, and each NXentry is of the form seen in Fig. 1. 
The key to NeXus is that while very little information 
is required, if it is to be included in the file it has to be 
included in the manner specified by the standard. 

The Integrated Spectral Analysis Workbench (ISAW) 
was designed to visualize and analyze data taken at time- 
of-flight neutron sources. In order to appeal to a broader 
community it looked to support the NeXus format. The 
data acquisition system (DAS) team at the Manuel Lujan 
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FIG. I: Schematic of the format of a general NXentry. The 
NXdata shown is typical of one dimensional id arrays. 



Jr. Neutron Scattering Center (MLNSC) was working on 
an upgrade of their system which included moving to a 
more widely used file format to reduce some of the work 
involved in analyzing data. Immediately the two groups 
tried to share files and found that, while the data could 
be written by one system and loaded into the other, much 
information was lost due to organizational differences. To 
solve this problem the authors decided to specify what 
needed to be included in a time-of-flight neutron powder 
diffractometer (TOFNPD) file. While this is a concep- 
tually simple instrument, information such as detector 
position is needed by many other instruments. This pa- 
per will discus several of the decisions made during a 
meeting at Los Alamos National Laboratory concerning 
the description of detectors. 



II. IDENTIFYING DETECTOR PIXELS 

In NeXus, data is stored as a multidimensional rect- 
angular array inside the NXdata object as seen in Fig. 1 
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FIG. 2: Schematic of an simple tube detector (a), LPSD (b), 
and area detector (c) split into its component pixels. 

with separate arrays for the independent variable and 
the detector identifiers. For a simple instrument, with 
only tube detectors (Fig. 2(a)), the data is two dimen- 
sional (data[i , j] ) with the first axis being time-of- flight 
(time_of .flight [i] ) and the second axis being detector 
number (id[j]). Newer powder diffractometers tend to 
use linear position sensitive detectors (LPSD) (Fig. 2(b)) 
which would store data in a three dimensional data ar- 
ray, (data[i, j ,k] ) with the first axis being the same as 
the simple tube (time_of .flight [i] ) and the other axes 
representing the detector and pixel number (id[j,k]). 
The case for area detector (Fig. 2(c)) is easy to extend 
from these two cases with a four dimensional data ar- 
ray (data[i,j ,k,l]), with the axes being time-of- flight 
(time_of .flight [i] ), detector number, row, and col- 
umn (id[j,k,l]). Since NeXus only provides for rect- 
angular arrays the case of an instrument with more than 
one type of detector must store the data in multiple NX- 
data. This is also the case when there is more than one 
time-of-flight range. To this end the group decided that 
if two data arrays have the same name attribute then 
they are intended to be part of the same data set. 



III. DESCRIBING DETECTORS 

Arguably the most important information, after the 
data, is a description of the detector configuration. The 
detector's position is needed for conversions to wave- 
length (A), (i-spacing, and momentum transfer (Q) as 
well as data corrections such as inelastic scattering. The 
solid angle covered is needed to normalize the spectra for 
measurement area effects. Other information is useful 
for diagnostics such as physical size (length, width, and 
depth), orientation, electronics configuration, and type 
(such as 3 He or scintillator). Some information about 
the detector is redundant as well. For example if the size 
and orientation is known then the solid angle covered is 
straightforward to calculate and does not need to be ex- 
plicitly included. This section will discus some of the 
properties of a detector. 
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FIG. 3: Schematic of a detector at a distance r from the center 
of the instrument. The angles a and /3 are arbitrarily labeled 
and discussed in the text. 



A. Specifying Position 

Due to the differences in preferred coordinate sys- 
tems and the variety of naming conventions, specifying 
a detector position is more difficult than one would ex- 
pect. While the choice of spherical coordinates is fairly 
straightforward, the decision of what to call the angles, 
and what to reference them from, was a long topic of dis- 
cussion. With diffraction experiments the beam direction 
is always special since things such as the Bragg angle 3 are 
with respect to it. Due to this symmetry the preferred 
coordinate system is spherical with the pole coinciding 
with the beam direction. This is shown in Fig. 3 with 
the azimuthal angle being zero at the horizontal plane of 
the instrument. The zero point for the azimuthal angle 
was chosen to be in the horizontal plane, to coincide with 
the location of detectors on many diffractometers and to 
be consistent with the traditional labeling of detector po- 
sition. The angles labeled in the figure are some of the 
standard choices used with spherical coordinates. The 
one way that the group could speak and not have any 
inconsistencies was discussing the angle a as the polar 
angle and /3 as the azimuthal angle. Other possibilities 
for a were Bragg angle, 29, 9, and 4>. (3 was also possibly 
9 or (p. All greek labels are used in most mathemat- 
ics texts, (except 29) however, their interpretations vary 
greatly. For this reason we decided that the most pre- 
cise way to refer to the angles were as polar_angle and 
azimuthal_angle. 



B. Specifying Orientation and Size 

Another important correction in data analysis is to 
normalize the detectors by the solid angle they cover. 
Therefore, the information needed is either the solid an- 
gle itself, or the physical size (length, width, and depth) 
and orientation of the detector so the solid angle can be 
calculated. In Fig. 4 a couple of the ways of determining 
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FIG. 4: Schematic of specifying the orientation of a detector 
with various possible frames of reference. The labels (do, di, 
and cfe) are described in the main text. 



the detector orientation are shown, do is the coordinates 
of the center of the instrument, shown for clarity. The 
second frame of reference, d\, is parallel to rf but shifted 



to the position of the detector. c?2 is coincident with the 
major symmetry axes of the detector. Looking at this 
picture the simplest description of the orientation is the 
Eider angles to rotate d% to d 2 . 



IV. SUMMARY 

This paper reviewed the results of discussions concern- 
ing storing data in a NeXus file. We described the format 
for the data itself as well as specifying the layout of the 
detectors that measured the data. 
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